thumbnail
반응형 웹 이미지 배치 전략
Frontend
2023.04.12.

썸네일: UnsplashPaul Hanaoka

출처 : 웹 성능 최적화 기법


웹 성능 최적화 기법(루비페이퍼 사) 도서에 대한 핵심 내용과 지식을 정리한 포스트입니다. 포스트에 올라오는 내용은 도서의 일부이기 때문에 더 자세한 내용이 궁금하신 분들은 출처에서 도서를 구매해 읽어보시는 것을 추천드립니다.


4.4 반응형 웹에서의 이미지 배치 전략

  • 모바일 사용자들의 웹 사이트 접속이 증가하면서 웹 사이트 구현 추세의 변화가 생김
    • 초기 : 모바일 전용 사이트를 별도 구축(m.(엠닷 사이트))
    • 엠닷 사이트의 문제점
      • 사이트 하나만으로는 다양한 모바일 기기의 사용자를 만족시킬 수 없게 됨
      • 데스크톱용 사이트, 모바일 사이트 별도로 관리되어 유지보수 비용과 시간 소요
      • 모바일 사용자 사용성 문제 (데스크톱과 차별화된 환경)
    • 위와 같은 문제점으로 반응형 웹 개념이 등장함
    • 반응형 웹이란 TV, PC, 태블릿, 스마트폰 등 각종 기기가 제공하는 화면 크기에 맞추어 최적화된 웹 페이지를 제공하는 것
      • 기기별로 웹 사이트를 따로 구축하지 않아도 되며, 사용성도 개선됨
      • SEO 측면에서도 구글에서 반응형 웹 사이트에 Mobile-Friendly라는 타이틀과 함께 검색 우선순위를 높일 수 있는 환경을 제공해줌

4.4.1 반응형 웹의 문제점

  • 반응형 웹 초창기에는 데스크톱과 모바일 기기에서 똑같은 사용자 경험을 제공한다는 측면에서 장점이 있었지만, 성능은 그렇지 못함
  • 반응형 웹은 화면 크기가 달라져도 웹 성능이 모두 동일하다는 결과가 나왔고, 모바일 환경에서는 인터넷이나, 기기 성능 등의 문제로 인해 사용자 경험을 오히려 저하시키게 됨

4.4.2 원인은 이미지

  • 위와 같은 문제점의 주된 원인은 바로 이미지 크기가 웹 환경에 따라 변하지 않는다는 점이다.
  • 반응형 웹을 만들 때는 break point(사이즈가 변화하는 지점)을 정의하고 그에 맞추어 화면을 디자인 한다.
    • 미디어 쿼리, 가변 그리드, 유동형 이미지 등의 기술을 적용해서 미디어 쿼리가 사용자의 환경을 감지하고 가변 그리드가 페이지 레이아웃을 구성하면 그 안의 이미지가 자동으로 확장/축소 되면서 화면을 표현
  • 개발 단계에서는 우선 고사양 데스크톱, 넓은 화면 모니터, 유선 네트워크로 빠르게 개발 및 테스트를 진행하고, 그 다음 화면 크기를 변경하여 웹 페이지가 작아지는지 테스트한다.
    • 이때, 화면이 작아져도 파일의 크기도 작아지지는 않아 웹 리소스들을 과하게 내려받는 현상(over-downloading)이 발생하게 된다.
    • over-downloading은 다음 3가지 유형으로 구분된다.
      • 내려 받아 줄이기(download and shrink)
      • 내려받아 숨기기(download and hide)
      • 화면 바깥 부분(below the fold)

내려받아 줄이기(download and shrink)

  • 반응형 웹에서는 화면의 크기가 변할 때마다 나타나는 이미지의 가로세로 크기가 달라지므로 고정된 값을 사용할 수 없으므로, 전체 화면 대비 이미지 영역의 비율 값을 사용한다. (유동형 이미지)
  • 이때, 유동형 이미지를 사용한다고 해서 실제 이미지가 작아지는 것은 아니므로 브라우저는 큰 이미지를 다운로드해 작게 축소하는 처리를 하고, 실시간으로 줄어든 가로x세로 값을 계산하는 과정이 추가된다.
    • 단점으로는 과도하게 큰 이미지를 다운로드 하려고 네트워크를 낭비하며, 축소하는 리소스와 시간이 낭비된다는 점이 있다.

내려받아 숨기기(download and hide)

  • 반응형 웹이 데스크톱과 모바일 환경에서 동일한 사용자 경험을 제공하지만, 데스크톱의 화면이 더 큰 만큼 더 많은 정보가 들어가기 마련이며, 모바일에는 불필요한 리소스들이 존재하게 된다.
@media only screen and (max-width: 771px)

.block-related {
	display: none
}
  • 위 CSS 코드를 예시로 들면 미디어 쿼리를 사용해 모바일 기기 크기를 감지해 display:none을 통해 요소를 숨기는 것을 볼 수 있는데, 브라우저에서는 숨긴다고 알아서 리소스를 다운로드 하지 않는 것이 아니라, 리소스를 먼저 모두 다운 받고 화면에 표현할지 안 할지 만을 결정하게 된다.

화면 바깥 부분 (below the fold)

  • fold란 사전적 의미로 접힌 부분을 뜻하며, below the fold는 접혀서 보이지 않는 부분을 의미한다.
  • 웹사이트에서는 화면 안쪽 부분이 비즈니스 목표 달성에 있어서 가장 중요한 역할을 하는데, 바깥쪽 이미지들로 인해 페이지 로딩 속도 저하, 화면 안쪽 내용 로딩 속도 저하 등 문제가 발생하여 사용자 경험을 저하시키는 원인이 된다.

4.4.3 반응형 이미지

  • 반응형 웹의 단점들은 결국 모바일 환경에서 필요하지 않은 리소스들을 과도하게 다운로드 한다는 문제로 귀결된다.
  • 리소스들은 HTML, 자바스크립트, CSS, 이미지를 포괄하지만 그중 약 65%를 차지하는 이미지의 비중이 가장 크다 할 수 있다.
  • 이 문제를 해결하는 방법으로는 사용자 환경에 따라 환경에 적합한 이미지를 전송하는 방법으로 해결할 수 있 다. 이런 이미지를 반응형 이미지라고 한다.

4.4.4 반응형 이미지 구현 방법

  • 반응형 이미지 구현은 두 가지 측면에서 접근할 수 있다.

1. 프론트엔드 측면에서의 구현

  • 미디어 쿼리를 사용해 클라이언트 환경을 파악한 후, 환경에 맞는 이미지 파일을 호출하도록 웹 페이지를 구현한다.
  • <img> 태그의 srcset 속성이나 <picture> 태그를 사용해 표준 방식으로 구현 가능하다.
  • 과도하게 사용할 경우 프론트엔드 코드가 무거워져 성능에 영향을 줄 수 있다.

srcset과 size 속성

  • srcset은 HTML <img> 태그 속성으로 다양한 환경에 따라 다른 이미지 URL을 지정할 수 있도록 한다.
<!-- srcset 속성을 활용한 예시 -->

<img src="small.jpg" alt="rwd"
srcset="pic-normal.jpg 1x,
				pic-retina.jpg 2x">

<!-- size 속성을 활용한 예시 -->
<img src="small.jpg" alt="rwd"
srcset="pic-normal.jpg 200w,
				pic-retina.jpg 400w"
size="(max-width: 400px) 100vw, (max-width: 800px) 30vw, 300px"
>
  • 1x, 2x는 화소밀도를 나타내며, size 속성을 사용할 경우에는 width 정보를 정의해야 한다.
  • 위 코드에서서는 화면의 크기가 0~400픽셀일 때 이미지 사이즈를 전체 뷰포트의 100%로 표현하도록 정의한다.
    • vw는 viewport width를 의미하며 1vw는 전체 뷰포트의 1% 크기를 뜻한다.
    • 화면의 크기가 401~800픽셀일 경우 전체 뷰포트의 30% 크기로 표현된다.
<!-- picture 태그 -->
<picture>
	<source media="(min-width: 45em)" srcset="large.jpg, large-hd.jpg 2x">
	<source media="(min-width: 18em)" srcset="med.jpg, med-hd.jpg 2x">
	<source srcset="small.jpg, small-hd.jpg 2x">
	<img src="small-1.jpg" alt="rwd">
</picture>
  • <picture> 태그는 <img> srcset의 단점을 모두 보완하며, 내부적으로 <source> 태그를 사용해 다양한 이미지 URL을 설정하게 한다.
  • 이때 미디어 쿼리를 사용해 URL 로딩 조건을 구체적으로 정의할 수 있어, 정의된 조건에 맞는 이미지한 사용하도록 브라우저를 강제할 수 있다.
  • <picture> 태그를 사용하면 HTML 소스가 다소 길어지고, 모든 브라우저가 지원하지 않는다는 단점이 있다.

2. 백엔드 측면에서의 구현

  • 서버에서 클라이언트의 환경에 맞는 이미지를 선택하여 전송하는 방법이다.
  • 프론트엔드 코드가 추가되지 않아 성능 향상이 가능하지만, 클라이언트 환경을 어떻게 파악할 지에 관한 문제와 서버 측 프로그램이 추가되어야 하는 번거로움도 있다.

Art direction

  • srcset, <picture> 태그를 사용해도 반응형 이미지가 사용자 환경에 따라 자동으로 변하지 않는다는 점은 해결할 수 없다.
    • 하나의 원본 이미지에 화면 크기별, 해상도별, 브라우저별로 적합한 이미지를 만드는 노력과 시간이 필요한데, 이를 Art direction이라고 한다.
  • 이미지에 따라 보여주고 싶은 대상이 다를 수 있는데, 이럴 경우 단순히 이미지 축소를 하면 원하는 초점이 달라질 수 있어 crop을 이용해서 적합한 이미지를 만들어야 한다.

Client Hints

  • Client Hints는 웹페이지를 호스팅하는 서버에서 사용자 환경을 고려해 응답할 내용을 최적화한 후 브라우저에 전달하는 방안이 도입되고 있다.
  • 현재 HTTP Working Group에서 구글 주도 하에 Internet-Draft 버전으로 논의를 진행 중이다.
  • Client Hints 헤더는 HTTP 헤더 일부로 포함되어 전송되며, 서버는 이 정보를 기반으로 응답 내용을 최적화해 다시 브라우저에 전송할 수 있다.

동작 방식

  • 브라우저에서 최초 서버로 HTTP 요청을 보낸다.
  • 서버는 응답 헤더에 Accept-CH를 추가해 Client Hints를 지원하고 있음을 브라우저에게 알린다.
Accept-CH : DPR, Width, Viewport-Width
  • 브라우저에서는 하위 리소스에 대한 요청부터 아래와 같은 관련 정보를 헤더에 추가해 보낸다.
DPR : 2.0
Width : 320
Viewport-Width : 320
  • 서버는 최적화된 이미지를 전송한 후 사용한 DPR 정보를 마지막 응답 메시지로 보낸다.
    • 이 DPR 정보는 브라우저가 서버로부터 받은 이미지를 처리할 때 사용된다.
Content-DPR : 1.0

이미지 지연 로딩

  • 앞선 방법들은 below the fold 이미지를 최적화하지 못한다는 문제점이 있어, JavaScript를 사용한 지연 로딩 방법이 권장된다.
function loadReal(img) {
	if(img.display !=== "none") {
		img.onload = null;
		img.src = img.getAttribute('data-src');
	}
}

<img src="1px.gif" data-src="book.jpg" alt="A Book" onload="loadReal(this)">
  • src에는 가짜 이미지가 링크 되어 있고, onLoad 이벤트가 발생할 때 loadReal 함수를 호출한다.
    • img Element가 현재 페이지에서 사용자들에게 노출될 수 있는 상태인지 체크하여, 가능한 경우에만 실제 이미지 정보를 링크시켜 다운받을 수 있도록 한다.
  • 오픈 소스에는 지연 로딩을 지원하는 다양한 라이브러리 등이 있다.

4.5 적응형 이미지 전략

  • 모바일 기기 인터넷 속도는 데스크톱에 비해 느리며 데이터 용량에도 제한이 있기 때문에, 데스크톱과 똑같은 대용량 웹 페이지를 그대로 내려받는 것은 매우 비효율적이며, 이를 해결하고자 서버 측 반응형 웹 접근 방법이 등장했다.
  • 서버 측 반응형 웹 접근 방법이란, 서버에서 클라이언트 정보를 파악해 맞춤형 웹 페이지를 생성하여 전송하는 방식을 의미한다.
    • 일반 반응형 웹은 서로 다른 기기별 요청에 동일한 대용량의 응답을 다운로드하고, 클라이언트 측에서 화면 크기에 맞게 콘텐츠를 적용시킨다.
    • 서버 측 반응형 웹은 기기별 요청을 서버에서 감지하고 각 기기에 적합한 콘텐츠를 만들어 응답한다.
  • 적응형 이미지란, 서버 측 반응형 웹 구현시에 필수적인 이미지 호출 방식이다.

4.5.1 적응형 이미지 아키텍처

  • 기존 웹 아키텍처와의 차이점
    1. 요청 클라이언트 정보를 감지
    2. 클라이언트 맞춤형 데이터를 로딩하는 서버 로직 추가
  • 적응형 이미지 아키텍처에서 가장 중요한 부분은 클라이언트 정보를 어떻게 감지하느냐이다. 반응형 웹은 미디어 쿼리를 사용했지만, 서버 측 반응형 웹에서는 클라이언트 정보를 알 방법이 없다.
  • Client Hints 스펙이 있긴 하지만 아직 지원하지 않는 브라우저도 다수 존재한다. (2023-4월 기준, 커버리지 약 74%)
    • HTTP 요청의 User-Agent 헤더를 통해 클라이언트의 정보를 알 수 있다.
    • User-Agent에는 브라우저 정보, 버전, 플랫폼, 시스템, 기타 사용자 정보 등이 담겨 있다.
  • 그 외에도 뷰포트, 스크린 크기, 화소 밀도 등 정보는 다음의 여러 가지 유료 솔루션을 통해 정보를 수집할 수 있다.
    • DeviceAtlas
    • ScientiaMobile/Wurf
    • 51degree

4.5.2 기기 정보에 따라 서버 로직 수행

  • 관련 정보 수집 후 클라이언트 환경에 맞는 이미지 파일을 링크에 연결한 후, 서버는 다음과 같은 로직으로 실행한다.
    1. 브레이크 포인트를 사전 정의한다. (여러 브레이크 포인트 별로 개수에 맞는 이미지를 준비)
    2. 검출된 기기 너비를 추출한다.
    3. 추출 너비가 브레이크 포인트보다 작다면 그 포인트에 해당하는 이미지 로드
    • 일반적으로 브레이크 포인트는 모바일, 태블릿, 데스크톱 3개의 포인트를 설정한다.

4.5.3 브라우저별 이미지 전달

  • 브라우저별 이미지는 HTTP 요청의 Accept 헤더를 참고해 결정할 수 있다.
  • 단 사파리는 Accept 헤더에 별도 표시를 하지 않아 검출 솔루션에 의존해야 한다.

4.5.4 캐시 고려 사항

  • 서버 측 반응형 웹과 적응형 이미지를 구성할 때 이미지를 캐시하는 경우가 많지만, 동일한 URL을 사용해도 사용자 기기에 따라 다른 이미지가 응답될 수 있어 캐시 충돌 현상에 주의해야 한다.
  • 캐시 충돌 현상을 피하려면 서버에서 응답 시 Vary 헤더를 활용해 특정 헤더에 따라 콘텐츠가 달라질 것이라고 캐시 서버에 알려줘야 한다.

© 2022 Developer Abel, Powered By Gatsby.